This is Part 3 of registration function generation.

This generates `__cuda_module_dtor`. It cannot be placed in global dtors
list, as treating it as a normal destructor will result in double-free
in recent CUDA versions (see comments in OG). Rather, the function is
passed as callback of `atexit`, which is called at the end of
`__cuda_module_ctor`.

Traditional clang implementation:
https://github.com/llvm/clangir/blob/a1ab6bf6cd3b83d0982c16f29e8c98958f69c024/clang/lib/CodeGen/CGBuiltin.cpp#L3618-L3632

The problem here is that `__builtin_clz` allows undefined result, while
`__lzcnt` doesn't. As a result, I have to create a new CIR for
`__lzcnt`. Since the return type of those two builtin differs, I decided
to change return type of current `CIR_BitOp` to allow new `CIR_LzcntOp`
to inherit from it.

I would like to hear your suggestions. C.c. @Lancern

This PR adds support for compiling builtin variables like `threadIdx`
down to the appropriate intrinsic.

---------

Co-authored-by: Aidan Wong <[email protected]>
Co-authored-by: anominos <[email protected]>

I have now fixed the test. Earlier I made some commits with other
changes because we were testing something on my fork. This should be
resolved now

CIR is currently ignoring the `signext` and `zeroext` for function
arguments and return types produced by CallConvLowering.

This PR lowers them to LLVM IR.

I realized I committed a new file with CRLF before. Really sorry about
that >_<

Related: llvm#1404

The choice of adding a separate file imitates that of OG.

This PR removes a useless argument `convertToInt` and removes hardcoded
`Sint32Type`.

I realized I committed a new file with CRLF before. Really sorry about
that >_<

There are some subtleties here.

This is the code in OG:
```cpp
// note: this is different from default ABI
if (!RetTy->isScalarType())
  return ABIArgInfo::getDirect();
```
which says we should return structs directly. It's correct, has have the
same behaviour as `nvcc`, and it obeys the PTX ABI as well.
The comment dates back to 2013 (see [this
commit](llvm/llvm-project@f9329ff)
-- it didn't provide any explanation either), so I believe it's
outdated. I didn't include this comment in the PR.

…lvm#1486)

The pattern `call {{.*}} i32` mismatches `call i32` due to double spaces
surrounding `{{.*}}`. This patch removes the first space to fix the
failure.

…1487)

This PR resolves an assertion failure in
`CIRGenTypes::isFuncParamTypeConvertible`, which is involved when trying
to emit a vtable entry to a virtual function whose type includes a
pointer-to-member-function.

Lower neon vabsd_s64

…lvm#1431)

Implements `::verify` for operations cir.atomic.xchg and
cir.atomic.cmp_xchg

I believe the existing regression tests don't get to the CIR level type
check failure and I was not able to implement a case that does.

Most attempts of reproducing cir.atomic.xchg type check failure were
along the lines of:
```
int a;
long long b,c;
__atomic_exchange(&a, &b, &c, memory_order_seq_cst);
```

And they seem to never trigger the failure on `::verify` because they
fail earlier in function parameter checking:
```
exmp.cpp:7:27: error: cannot initialize a parameter of type 'int *' with an rvalue of type 'long long *'
    7 |     __atomic_exchange(&a, &b, &c, memory_order_seq_cst);
      |                           ^~
```

Closes llvm#1378 .

Lower neon vcaled_f64

This PR adds a new boolean flag to the `cir.load` and the `cir.store`
operation that distinguishes nontemporal loads and stores. Besides, this
PR also adds support for the `__builtin_nontemporal_load` and the
`__builtin_nontemporal_store` intrinsic function.

This PR adds a new boolean flag to the `cir.load` and the `cir.store`
operation that distinguishes nontemporal loads and stores. Besides, this
PR also adds support for the `__builtin_nontemporal_load` and the
`__builtin_nontemporal_store` intrinsic function.

Resolves llvm#1477 .

Lower vcales_f32

This PR adds an insertion guard for the try body scope for try-catch.
Currently, the following code snippet fails during CodeGen:

```
void foo() {
  int r = 1;
  try {
    ++r;
    return;
  } catch (...) {
  }
}
```

The insertion point doesn't get reset properly and the cleanup is being
ran for a wrong/deleted block causing a segmentation fault. I also added
a test.

The comments suggested that we should use TableGen to generate the
recognizing functions. However, I think templates might be more suitable
for generating them -- and I can't find any existing TableGen backends
that let us generate arbitrary functions.

My choice of design is to offer a template to match standard library
functions:
```cpp
// matches std::find with 3 arguments, and raise it into StdFindOp
StdRecognizer<3, StdFindOp, StdFuncsID::Find>
```
I have to use a TableGen'd enum to map names to IDs, as we can't pass
string literals to template arguments easily in C++17.

This also constraints design of future `StdXXXOp`s: they must take
operands the same way of StdFindOp, where the first one is the original
function, and the rest are function arguments.

I'm not sure if this approach is the best way. Please tell me if you
have concerns or any alternative ways.

…was set explicitly (llvm#1482)

This is backported from a change made in
llvm/llvm-project#131181

---------

Co-authored-by: Morris Hafner <[email protected]>

…R attribute. (llvm#1467)

Started decorating CUDA shadow variables with the shadow_name CIR
attribute which will be used for registering the globals.

Closes llvm#1354.

Lower neon vcaltd_f64

… target was set explicitly" (llvm#1509)

Reverts llvm#1482

@mmha this is crashing on macos on asserts build:
```
FAIL: Clang :: CIR/Tools/cir-translate/warn-default-triple.cir (472 of 552)
******************** TEST 'Clang :: CIR/Tools/cir-translate/warn-default-triple.cir' FAILED ********************
Exit Code: 134

Command Output (stdout):
--
Assertion failed: (!DataLayoutString.empty() && "Uninitialized DataLayout!"), function getDataLayoutString, file TargetInfo.h, line 1282.
```

Perhaps besides picking a default you maybe need to do some missing
datalayout init?

llvm/llvm-project#132269

Backporting passing enum kind directly to complex cast helpers

…ent (llvm#1748)

## Overview
Currently, getting the pointer to an element of an array requires a
pointer decay and a (possible) pointer stride. A similar pattern for
records has been eliminated with the `cir.get_member` operation. This PR
provides a similar level of abstraction for arrays with the
`get_element` operation.
`get_element` replaces the above pattern with a single operation, which
takes a pointer to an array and an index, and produces a pointer to the
element at that index.
There are many places in CIR analysis and lowering where the
`ptr_stride(array_to_ptrdecay(x), i)` pattern is handled as a special
case. By subsuming the special case pattern with an explicit operation,
we make these analyses and lowering more robust.

## Changes
Adds the `cir.get_element` operation.
Extends CIRGen to emit `cir.get_element` for array subscript
expressions.
Updated LifetimeCheck to handle `get_element` operation, subsuming
special case analysis of `cir.ptr_stride` operation (did not remove the
special case).
Extends CIR-to-LLVM lowering to lower `cir.get_element` to
`llvm.getelementptr`
Extends CIR-to-MLIR lowering to lower `cir.get_element` to `memref`
operations, matching existing special case `cir.ptr_stride` lowering.

## Additional Notes
Currently, 47.6% of `cir.ptr_stride` operations in the llvm-test-suite
(SingleSource and MultiSource) can be replaced by `cir.get_element`
operations.

### Operator Breakdown (current)
name | count | %
-- | -- | --
cir.load | 825221 | 22.27%
cir.br | 429822 | 11.60%
cir.const | 380381 | 10.26%
cir.cast | 325646 | 8.79%
cir.store | 309586 | 8.35%
cir.get_member | 226895 | 6.12%
cir.get_global | 186851 | 5.04%
cir.ptr_stride | 158094 | 4.27%
cir.call | 144522 | 3.90%
cir.binop | 141142 | 3.81%
cir.alloca | 134346 | 3.63%
cir.brcond | 112864 | 3.05%
cir.cmp | 83532 | 2.25%

### Operator Breakdown (with `get_element`)
name | count | %
-- | -- | --
cir.load | 825221 | 22.74%
cir.br | 429822 | 11.84%
cir.const | 380381 | 10.48%
cir.store | 309586 | 8.53%
cir.cast | 248645 | 6.85%
cir.get_member | 226895 | 6.25%
cir.get_global | 186851 | 5.15%
cir.call | 144522 | 3.98%
cir.binop | 141142 | 3.89%
cir.alloca | 134346 | 3.70%
cir.brcond | 112864 | 3.11%
cir.cmp | 83532 | 2.30%
cir.ptr_stride | 81093 | 2.23%
cir.get_elem | 77001 | 2.12%

---------

Co-authored-by: Andy Kaylor <[email protected]>
Co-authored-by: Henrich Lauko <[email protected]>